Nun, Einplanungsverfahren werden unterschiedlich eingeordnet. Sie unterliegen einer bestimmten

Klassifikation und das wollen wir uns zunächst einmal anschauen, bevor wir zu den Verfahrensweisen

selbst kommen. So kennen wir einmal kooperative oder präemptive Verfahren. Hier ist letztendlich

die Frage, wer ist denn hier souverän? Ist es die Anwendung, also das Maschinenprogramm oder die

Menge von Maschinenprogrammen oder das Betriebssystem selbst? Die kooperative Planung ist eine

Ein- und Umplanung von einander abhängigen Prozessen. Hier ist es eben nicht so, dass das

Betriebssystem den Prozessen, die CPU, einfach vollkommen eigenständig entzieht und nach Belieben

auf die Prozesse, die lauffähig sind, verteilt, sondern die Prozesse selbst müssen sich dazu

bereit erklären. Sie müssen sich anderen Prozessen gegenüber kooperativ, aber auch

dem Betriebssystem gegenüber kooperativ verhalten, den Prozessor, die CPU, abgeben zu wollen. Das

tun sie mittels Systemaufrufe. Das heißt also, wann immer ein Systemaufruf dann getätigt wird,

dann wird die Behandlung dieses Systemaufrufs implizit dazu führen, den Scheduler, den Planer

zu aktivieren, der dann halt entsprechend seiner Reihenfolgeplanung die Prozesse letztendlich

auf die Wartelisten für die CPU dann entsprechend setzt bzw. diese Warteliste in entsprechender

Art und Weise dann halt umsortiert. Wenn nun keine Systemaufrufe in den Maschinenprogrammen

stattfinden, hat man hiermit ein Problem. Das gilt insbesondere dann, wenn die Maschinenprogrammen

endlos schleifen letztendlich enthalten, dann würde man sagen, naja, sind sie nicht kooperativ,

sie setzen eben doch keine Systemaufrufe ab und dann kann es eben auch nicht weiter zu einer

Einplanung kommen. Das führt dann dazu, dass wir eine CPU-Monopolisierung haben. Die ist also leicht

möglich, nämlich immer genau dann, wenn die Prozesse immer komplett bis zur Beendigung

durchlaufen und wenn sie überhaupt nicht zum Ende kommen, dann hat man natürlich ein großes

Problem in diesem System. Demgegenüber steht die sogenannte präemptive Planung. Hier sagt man,

die Prozesse sind eben unabhängig voneinander. Hier muss also nie kein Prozess letztendlich

Rücksicht auf den anderen Prozess oder Rücksicht auf das Betriebssystem nehmen. Hier gibt es

Ereignisse, die vom Betriebssystem halt behandelt werden. Das sind Ereignisse, die werden durch die

Hardware signalisiert. Das können Zeitgeberereignisse sein, Timer, das können ein Ausgabereignisse sein,

die über die Peripherie ins System dann einfließen, die dazu führen, dass eine Ereignisbehandlung

aktiviert wird, die dann halt den Scheduler aktiviert und es dann praktisch aufgrund dieser

Ereignisbehandlung, also ereignisbedingt, eben zur Umplanung der CPU kommen kann. Das bedeutet eben

auch, dass der auf der gerade auf der CPU laufende Prozess möglicherweise die CPU entzogen bekommt.

Wir sagen, er wird verdrängt. Es gibt ein anderer Prozess, der praktisch eine Bevorrichtigung besitzt,

die CPU sozusagen jetzt zu erhalten. Damit ist dann letztendlich auch die Monopolisierung der

CPU nicht mehr so einfach möglich. Wir sprechen auch davon, dass das Betriebssystem oder ein

Planer, der präemptiv arbeitet, CPU-Schutz im System implementiert. Nun kann man sich auch eine

Synergie gut vorstellen, die durchaus bei den heutigen Systemen gang und gäbe es. Auf der

Maschinenprogramm-Ebene hat man häufig kooperative User-Threats, wohingegen wir auf der Betriebssystem-Ebene

eben präemptive Kernel-Threats letztendlich haben. So, dann haben wir eine Einordnung dahingehend,

ob die Verfahren deterministisch oder probabilistisch arbeiten. Das bedeutet also,

ob wir im deterministischen Sinne in der Lage sind, durch Vorwissen, durch a priori wissen,

einfach bestimmte Prozessabläufe eindeutig festlegen zu können oder ob man sozusagen nur

nach Wahrscheinlichkeiten ausgehen muss, weil wir einfach so ein entsprechend ausreichendes

Vorwissen, ein komplettes Vorwissen eben nicht besitzen und dann halt nur noch vermuten können,

wann welche Prozesse im System denn zur Ausführung kommen können. Die deterministische Planung

bedeutet dann letztendlich auch, dass alle Prozesse bekannt sein müssen, dass insbesondere die

Laufzeiten, also die Rechenstoßlängen dieser Prozesse bekannt sein müssen und auch durchaus

Termine für diese Prozesse bekannt sind. Die Rechenstoßlängen sind häufig die maximale

Stoßlänge, die so ein Prozess jetzt durchführen kann. Das ist die sogenannte Worst-Case-Execution-Time.

Dafür gibt es Werkzeuge, die sind in der Lage durch Programmanalysen praktisch diese Längen zu

bestimmen, um dann letztendlich so an a priori wissen eben heranzukommen. Wenn man diese Information

hat, Anzahl der Prozesse, Länge der Prozesse, Termine der Prozesse, dann ist eine genaue